Logic analyzers and in-circuit emulators have been used for many years by software and hardware developers to help diagnose and debug hardware and software. Such devices may be able to monitor and analyze various circuit and software conditions during debugging and testing of the design. For example, they may store trace information, such as time stamps, register values, data memory content, etc., which may be later analyzed. They may also provide various configurable breakpoints, which allow the designer to analyze the state of the design at a point in its operation by stopping operation when a specified condition occurs. The breakpoints may be based on a series of conditions that must happen before the operation is stopped.
For example, conventional logic analyzers and in-circuit-emulators may have a relatively small number of custom designed complex breakpoints. A designer may cause the analyzing device to perform a specified action upon a condition's occurrence. For example, a first breakpoint might look for a write to a certain memory address. When the first breakpoint triggers, it activates a second complex breakpoint, which may look for a certain program counter value. When the program counter reaches that value, a third complex breakpoint is activated, which may watch for a certain stack pointer value. When the stack pointer reaches the specified value a fourth complex breakpoint is activated, which may watch for a certain accumulator value. Finally, when the accumulator value is reached the operation breaks.
Unfortunately, conventional analyzing devices offer only a few breakpoints, which are implemented as dedicated pieces of hardware, each designed to look for one condition. Because much of the hardware is dedicated to one function, it is prohibitively expensive to provide a substantial number of breakpoints. Consequently, only a limited number of events can be programmed and only a limited number of conditions can be monitored. Also, separate conventional systems are required to perform both logic analyzer and in-circuit-emulation functions. For example, conventional logic analyzers are able to monitor signals that an in-circuit-emulator would not normally analyze, such as signals that originate outside the circuit containing the emulator. Likewise a logic analyzer would not normally provide emulation functionality. Consequently, substantial added expensive must be taken to purchase and maintain both systems.
Furthermore conventionally, dedicated event hardware is designed to examine certain hardware resources. In order to perform a complex sequence of checks and then take an action based thereon in the conventional art, custom logic is needed to determine when the conditions checked for arose, and then to take appropriate action. The complexity of the logic required is determined conventionally by the complexity of the expressions needed. If complex expressions are required, then conventionally, complex custom logic is needed. Writing such custom, often complex logic is expensive, laborious, time-consuming, and adds further debugging needs. Complex conventional software tools generate such custom logic. Thus, writing custom complex logic requires writers to be versed in using complex circuit design tools.
Some conventional logic analyzers have a mechanism for a user to interface with it. However, some conventional logic analyzer interfaces have only a single point of execution. Also, they are not very user friendly. Conventional multi-channel logic analyzers have limited usefulness and lack user friendliness. For some number of logic inputs, conventional multi-channel logic analyzers allow monitoring some sequence of events. However, conventional multi-channel logic analyzers are problematic because there are no logical groupings for the inputs, and making logical connections between the inputs is laborious and confusing.
Conventional debugging software applies scripting techniques and has few or no user interfaces. They can be time demanding, even where they support multiple event occurrences. Upon execution of multiple sequences, conventional software debugging tools await a breakpoint. Upon reaching particular breakpoints, they may look for a certain conditions. However, their checking is not occurring at the high speeds at which the hardware they are observing runs. Thus, conventional software debugging tools typically cannot react rapidly to multiple deep sequences. Also, some of them may tend to be somewhat complicated to use. Setting up a single check may require several hundred lines of code, all of which needs to be debugged itself before use. Conventional debugging software may thus require inordinate time, labor and related costs and may not be perceived as particularly user friendly.